home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄7⁄90 / 1941-Re[2] Language Wars-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.7 KB  |  39 lines  |  [TEXT/GEOL]
  1. Item    9329612                         7-Sept-90        10:30PDT
  2.  
  3. From:   ALGER                           KPMG Peat Marwick, Jeff Alger,VCA
  4.  
  5. To:     PASCOE1                         Pascoe, Geoff
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: Re: Language Wars
  10.  
  11. Geoff,
  12.  
  13. Thank you for an excellent casting of the issues.  My personal - and still
  14. evolving - opinion is that generalized code reuse is largely an unreachable
  15. goal.  (Was that a collective gasp I just heard???)  Thus, I do not have a
  16. problem with the C++ shortcomings in that regard that you point out.  To be
  17. fair, I don't think Object Pascal is much better in promoting code reuse (it is
  18. a LITTLE better,) nor is any other language.
  19.  
  20. No code reuse?  What is this heresy?  Especially from one who has devoted a
  21. good deal of his career to trying to create reusable code?  Simply this: most
  22. computer software is terribly context-sensitive.  Libraries like MacApp carry
  23. only the context of the machine and operating system they run on.  The closer
  24. you get to an application, the bigger the contextual baggage and the less
  25. reusable your code will be; most of my code is close to the application, so my
  26. expectations are pretty low for reusability.
  27.  
  28. Maintainability, extensibility, and modularity are better objectives to set
  29. because they are limited in scope to the application at hand, and I find C++ to
  30. work fine in those regards - a LITTLE bit better than Object Pascal.  For those
  31. of us who live primarily in the application domain, the perspective is thus
  32. likely to be a little different than those focused on development of
  33. application-independent frameworks like MacApp.
  34.  
  35. Pouring more fuel on the fire,
  36. Jeff Alger
  37. KPMG•Exis
  38.  
  39.